Managing technology resources across multiple platforms

ABSTRACT

The present invention extends to methods, systems, and computer program products for managing technology resources across multiple platforms. Embodiments of the invention can be used to manage the configuration of a plurality of different devices. A management server/service can utilize native management capabilities of different devices to provide configuration management without requiring agents to be installed on the devices. In general, the management server/service adapts to the unique characteristics and behaviors of different devices, platforms, and external systems to provide configuration management for the different devices, platforms, and external systems. As such, configuration management can be provided in a unified fashion across different platforms, both on-premise and off-premise, and indirectly. When client agents are present, the management server/service can adjust to compatibly operate with the client agents.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims the benefit of andpriority to U.S. patent application Ser. No. 14/866,832 entitled“Managing Technology Resources Across Multiple Platforms”, filed Sep.25, 2015 by Steven P. Burns et al., the entire contents of which areexpressly incorporated by reference. That application is a continuationof and claims the benefit of and priority to U.S. patent applicationSer. No. 13/721,042, now U.S. Pat. No. 9,172,773, entitled “ManagingTechnology Resources Across Multiple Platforms”, filed Dec. 20, 2012 bySteven P. Burns et al., the entire contents of which are expresslyincorporated by reference.

BACKGROUND Background and Relevant Art

Computer systems and related technology affect many aspects of society.Indeed, the computer system's ability to process information hastransformed the way we live and work. Computer systems now commonlyperform a host of tasks (e.g., word processing, scheduling, accounting,etc.) that prior to the advent of the computer system were performedmanually. More recently, computer systems have been coupled to oneanother and to other electronic devices to form both wired and wirelesscomputer networks over which the computer systems and other electronicdevices can transfer electronic data. Accordingly, the performance ofmany computing tasks is distributed across a number of differentcomputer systems and/or a number of different computing environments.

In enterprise network environments, an information technology (IT)management group typically manages the configuration of computingdevices for an entity (e.g., a corporation). Larger networks can include100s or even 1000's computing devices, including personal computers,phones, tablets, etc. Different computing devices can have different andunique technologies and implementation details, such as, differenthardware and software. As a result, the required configurationmanagement for the different computing devices can also vary.

Some computing devices may be more easily managed than other computingdevices. For example, a widely adopted design for personal computerconfiguration management system is a client-server design. That is, aserver (or service) is contacted by an accompanying client, which istypically a software process (an ‘agent’) running on the computer beingmanaged. The client periodically contacts the server to receiveconfiguration directives and to submit data regarding the management ofthe computer running the agent. The server and the client to bedeveloped in tandem to increase interoperability.

On the other hand, when managing a mobile device (e.g., aslate/tablet/phone or similar), the client-server design often does notwork. For example, on many mobile devices the device operating platformdoes not allow for an agent to be installed on the device.Alternatively, a device manufacturer, distributor, supplier, carrier, orlicensing entity may not allow under the terms of the use of the device,the installation of an agent on the device (even if the operatingplatform does allow installation of an agent). For either of theseconfigurations, it is typically for a device platform to already includesome form of remote device management. That is, the device may alreadyhave some sort of management agent supplied by the device manufacturer.Additionally, the development of an agent for the device platform may beredundant with functionality already present on the device. Thus, evenif the device lends itself to the installation of a management agent, itmay not be attractive to develop one since doing so would provide littlevalue over functionality already present.

Further, some configuration management directives are not realized on adevice at all. Rather, such directives are to manage the configurationof other software systems on behalf of a user or device that utilizesthose systems. For example, an IT admin may desire to manage a user'semail in-box. However, the in-box is an artifact of the emailsystem—separate from an IT configuration management system. That is,devices access the email system to retrieve the email for a given user.These devices, in the context of email retrieval, respond to theconfiguration of the email system. Nonetheless, the IT admin would liketo specify management directives for the device's behavior that isgoverned by the email system. However, the email system is merely anintermediary for the indirect management of services.

Moreover, it is often the case that enterprises have existing andseveral systems in place that are installed “on premises,” meaning, thatthe enterprise owns and operates the equipment on which those systemsrun. Likewise, it is increasingly the case that enterprises utilizeservices provided over communications networks such as the Internet.These Internet services owned and operated by a third party. However, itcan be difficult to manage these external systems using a client-serverdesign.

It can also be difficult to manage a computing device when the client orserver component in a client-server design changes. For example, it maybe that a managed device has a native device client agent designed towork with a given IT management system. If the IT management systemchanges (e.g., due to an upgrade), the device client agent may becomeincompatible and require changes. In some environments, it may not evenbe possible to change the device client agent. For example, the deviceclient agent may be embedded in hardware (e.g., an embedded system) andcannot be revised.

BRIEF SUMMARY

The present invention extends to methods, systems, and computer programproducts for managing technology resources across multiple platforms. Insome embodiments, a directive dispatcher issues an abstract-deviceneutral directive to a specified (and possible one of many different)device(s). The abstract device-neutral directive directs the specifiedtarget device to implement a configuration change. A platform-specificgateway (possibly one of a plurality of different platform-specificgateways) for the specified target device receives the abstractdevice-neutral directive from a distribution component. Theplatform-specific gateway translates the abstract device-neutraldirective into a form suitable for execution at the specified targetdevice to implement the configuration change. The platform-specificgateway sends the form suitable for execution at the specified targetdevice to the specified target device so as to realize the configurationchange at the specified target device.

In other embodiments, a platform-specific gateway collects operationaldata from a specified target device. The operational data is in adevice-specific data format and relates to a previously issued directivefrom a directive dispatcher. The platform-specific gateway translatesthe operational data from the device-specific data format into thedevice-neutral data format in accordance with a device-neutral dataschema. The platform-specific gateway submits the operational data inthe device-neutral data format to a data collection service for storagein a data persistence store. The operational data is available forsubsequent use by business logic when processing issued directives fromthe directive dispatcher.

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

Additional features and advantages of the invention will be set forth inthe description which follows, and in part will be obvious from thedescription, or may be learned by the practice of the invention. Thefeatures and advantages of the invention may be realized and obtained bymeans of the instruments and combinations particularly pointed out inthe appended claims. These and other features of the present inventionwill become more fully apparent from the following description andappended claims, or may be learned by the practice of the invention asset forth hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features of the invention can be obtained, a moreparticular description of the invention briefly described above will berendered by reference to specific embodiments thereof which areillustrated in the appended drawings. Understanding that these drawingsdepict only typical embodiments of the invention and are not thereforeto be considered to be limiting of its scope, the invention will bedescribed and explained with additional specificity and detail throughthe use of the accompanying drawings in which:

FIG. 1 illustrates an example computer architecture that facilitatestranslating a device-neutral directive.

FIG. 2 illustrates a flow chart of an example method for translating adevice-neutral directive.

FIG. 3 illustrates an example computer architecture that facilitatestranslating a device-specific operational data.

FIG. 4 illustrates a flow chart of an example method for translatingdevice-specific operational data.

FIG. 5 illustrates an example computer architecture that facilitatesmanaging technology resources across multiple platforms.

DETAILED DESCRIPTION

The present invention extends to methods, systems, and computer programproducts for managing technology resources across multiple platforms. Insome embodiments, a directive dispatcher issues an abstract-deviceneutral directive to a specified (and possible one of many different)device(s). The abstract device-neutral directive directs the specifiedtarget device to implement a configuration change. A platform-specificgateway (possibly one of a plurality of different platform-specificgateways) for the specified target device receives the abstractdevice-neutral directive from a distribution component. Theplatform-specific gateway translates the abstract device-neutraldirective into a form suitable for execution at the specified targetdevice to implement the configuration change. The platform-specificgateway sends the form suitable for execution at the specified targetdevice to the specified target device so as to realize the configurationchange at the specified target device.

In other embodiments, a platform-specific gateway collects operationaldata from a specified target device. The operational data is in adevice-specific data format and relates to a previously issued directivefrom a directive dispatcher. The platform-specific gateway translatesthe operational data from the device-specific data format into thedevice-neutral data format in accordance with a device-neutral dataschema. The platform-specific gateway submits the operational data inthe device-neutral data format to a data collection service for storagein a data persistence store. The operational data is available forsubsequent use by business logic when processing issued directives fromthe directive dispatcher.

Embodiments of the present invention may comprise or utilize a specialpurpose or general-purpose computer including computer hardware, suchas, for example, one or more processors and system memory, as discussedin greater detail below. Embodiments within the scope of the presentinvention also include physical and other computer-readable media forcarrying or storing computer-executable instructions and/or datastructures. Such computer-readable media can be any available media thatcan be accessed by a general purpose or special purpose computer system.Computer-readable media that store computer-executable instructions arecomputer storage media (devices). Computer-readable media that carrycomputer-executable instructions are transmission media. Thus, by way ofexample, and not limitation, embodiments of the invention can compriseat least two distinctly different kinds of computer-readable media:computer storage media (devices) and transmission media.

Computer storage media (devices) includes RAM, ROM, EEPROM, CD-ROM,solid state drives (“SSDs”) (e.g., based on RAM), Flash memory,phase-change memory (“PCM”), other types of memory, other optical diskstorage, magnetic disk storage or other magnetic storage devices, or anyother medium which can be used to store desired program code means inthe form of computer-executable instructions or data structures andwhich can be accessed by a general purpose or special purpose computer.

A “network” is defined as one or more data links that enable thetransport of electronic data between computer systems and/or modulesand/or other electronic devices. When information is transferred orprovided over a network or another communications connection (eitherhardwired, wireless, or a combination of hardwired or wireless) to acomputer, the computer properly views the connection as a transmissionmedium. Transmissions media can include a network and/or data linkswhich can be used to carry desired program code means in the form ofcomputer-executable instructions or data structures and which can beaccessed by a general purpose or special purpose computer. Combinationsof the above should also be included within the scope ofcomputer-readable media.

Further, upon reaching various computer system components, program codemeans in the form of computer-executable instructions or data structurescan be transferred automatically from transmission media to computerstorage media (devices) (or vice versa). For example,computer-executable instructions or data structures received over anetwork or data link can be buffered in RAM within a network interfacemodule (e.g., a “NIC”), and then eventually transferred to computersystem RAM and/or to less volatile computer storage media (devices) at acomputer system. Thus, it should be understood that computer storagemedia (devices) can be included in computer system components that also(or even primarily) utilize transmission media.

Computer-executable instructions comprise, for example, instructions anddata which, when executed at a processor, cause a general purposecomputer, special purpose computer, or special purpose processing deviceto perform a certain function or group of functions. The computerexecutable instructions may be, for example, binaries, intermediateformat instructions such as assembly language, or even source code.Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the described features or acts described above.Rather, the described features and acts are disclosed as example formsof implementing the claims.

Those skilled in the art will appreciate that the invention may bepracticed in network computing environments with many types of computersystem configurations, including, personal computers, desktop computers,laptop computers, message processors, hand-held devices, multi-processorsystems, microprocessor-based or programmable consumer electronics,network PCs, minicomputers, mainframe computers, mobile telephones,PDAs, tablets, pagers, routers, switches, and the like. The inventionmay also be practiced in distributed system environments where local andremote computer systems, which are linked (either by hardwired datalinks, wireless data links, or by a combination of hardwired andwireless data links) through a network, both perform tasks. In adistributed system environment, program modules may be located in bothlocal and remote memory storage devices.

Embodiments of the invention can also be implemented in cloud computingenvironments. In this description and the following claims, “cloudcomputing” is defined as a model for enabling on-demand network accessto a shared pool of configurable computing resources. For example, cloudcomputing can be employed in the marketplace to offer ubiquitous andconvenient on-demand access to the shared pool of configurable computingresources. The shared pool of configurable computing resources can berapidly provisioned via virtualization and released with low managementeffort or service provider interaction, and then scaled accordingly.

A cloud computing model can be composed of various characteristics suchas, for example, on-demand self-service, broad network access, resourcepooling, rapid elasticity, measured service, and so forth. A cloudcomputing model can also expose various service models, such as, forexample, Software as a Service (“SaaS”), Platform as a Service (“PaaS”),and Infrastructure as a Service (“IaaS”). A cloud computing model canalso be deployed using different deployment models such as privatecloud, community cloud, public cloud, hybrid cloud, and so forth. Inthis description and in the claims, a “cloud computing environment” isan environment in which cloud computing is employed.

Embodiments of the invention can be used to manage the configuration ofa plurality of different devices. A management server/service canutilize native management capabilities of different devices to provideconfiguration management without requiring agents to be installed on thedevices. In general, the management server/service adapts to the uniquecharacteristics and behaviors of different devices, platforms, andexternal systems to provide configuration management for the differentdevices, platforms, and external systems. As such, configurationmanagement can be provided in a unified fashion across differentplatforms, both on-premise and off-premise, and indirectly. When clientagents are present, the management server/service can adjust tocompatibly operate with the client agents.

A data model design models managed devices in a device-neutral mannerService/server-side logic processes management directives in adevice-neutral format. Gateway adaptors reconcile platform-specifics tomanagement service generalisms. For example, gateway adaptors cantranslate device-neutral directives into device-specific directives.Gateway adaptors can also translate collected operational data fromdevice-specific format into a device-neutral format for use by theservice/server-side logic. Gateway adaptors can also adapt to variousprotocols used to communicate with devices. As such, gateway adaptorscan facilitate communication between endpoints that use differentcommunication protocols.

FIG. 1 illustrates an example computer architecture 100 that facilitatestranslating a device-neutral directive. Referring to FIG. 1, computerarchitecture 100 includes directive dispatcher 101, directive processingmodules 102, distribution component 103, platform-specific gateway 104,and target device 107. Each of directive dispatcher 101, directiveprocessing modules 102, distribution component 103, platform-specificgateway 104, and target device 107 can be connected to one another over(or be part of) a network, such as, for example, a Local Area Network(“LAN”), a Wide Area Network (“WAN”), and even the Internet.Accordingly, directive dispatcher 101, directive processing modules 102,distribution component 103, platform-specific gateway 104, and targetdevice 107 as well as any other connected computer systems and theircomponents, can create message related data and exchange message relateddata (e.g., Internet Protocol (“IP”) datagrams and other higher layerprotocols that utilize IP datagrams, such as, Transmission ControlProtocol (“TCP”), Hypertext Transfer Protocol (“HTTP”), Simple MailTransfer Protocol (“SMTP”), etc. or using other non-datagram protocols)over the network.

In general, directive dispatcher 101 is configured to issuedevice-neutral directives targeted to one or more specified targetdevices. The device-neutral directives can direct one or more specifiedtarget devices to implement a configuration change. When appropriate,directive processing modules 102 can process issued device-neutraldirectives to modify the device-neutral directives. Directive processingmodules 102 can apply business logic to make changes for specifiedtarget device or to comply with policy settings. In some embodiments,directive processing modules 102 includes a plurality of modules thatinteract with one another to provide various features offered to a user(e.g., an IT admin).

Distribution component 103 is configured to distribute a device-neutraldirective to one or more specified targeted devices. Distributioncomponent 103 can receive a device-neutral directive. From the devicesdistribution component 103 is aware of, distribution component 103 candetermine which devices are specified targeted devices of thedevice-neutral directive. Distribution component 103 can forward to thedevice-neutral directive on to the specified targeted gateways.

Platform-specific gateway 104 is configured to interface between moreabstract device-neutral directives issued by directive dispatcher 101and more concrete device-specific directives for target device 107 (andother similar devices). More specifically, translation module 106 cantranslate a device-neutral directive into a form suitable for executionat target device 107 (and other similar devices). In some embodiments,platform-specific gateway 104 is one of a plurality of differentplatform-specific gateways. Each of the plurality of differentplatform-specific gateways can be configured to interface between moreabstract device-neutral directives issued by directive dispatcher 101and more concrete device-specific directives for corresponding targetdevices. Each of the plurality of different platform-specific gatewayscan be configured for use with differently configured devices includingany of the previously described devices. For example, platform-specificgateway 104 can be configured for use with mobile phones, anotherplatform-specific gateway can be configured for use with personalcomputers, another platform-specific gateway can be configured for usewith network equipment, etc.

Target device 107 can be one of a variety of different devices, such as,for example, a personal computer, a mobile phone, a tablet, networkequipment, etc. or other previously described devices.

FIG. 2 illustrates a flow chart of an example method 200 for translatinga device-neutral directive. Method 200 will be described with respect tothe components and data of computer architecture 100.

Remaining briefly at FIG. 1, directive dispatcher 101 can dispatchdevice-neutral directive 111 to target device 107 (as well as one ormore other devices). Device-neutral directive 111 can direct targetdevice 107 (as well as the one or more other devices) to implement aconfiguration change. When appropriate, directive processing modules 102can apply business logic to device-neutral directive 111. Device-neutraldirective 111 is then passed on to distribution component 103 fordistribution. Distribution component 103 can determine thatdevice-neutral component has been issued to target device 107. Inresponse, distribution component 103 can forward device-neutraldirective 111 to platform-specific gateway 104.

In general, directives can include setting device configuration,collecting device hardware and software inventory, distribution ofupdates, patches, and applications to a device, issuing “wipe/rest”commands, etc. Device-neutral directive 111 can include any of these (aswell as other) directives.

Method 200 includes an act of a platform-specific gateway receiving anabstract device-neutral directive from a distribution component, theabstract device-neutral directive issued by a directive dispatcher, theabstract device-neutral directive directing a specified target device toimplement a configuration change (201). For example, platform-specificgateway 104 can receive device-neutral directive 111 from distributioncomponent 103. As described, device-neutral directive 111 was dispatchedfrom directive dispatcher 101 and directs target device 107 to implementa configuration change.

Method 200 includes the platform-specific gateway translating theabstract device-neutral directive into a form suitable for execution atthe specified target device to implement the configuration change (202).For example, translation module 106 can translate device-neutraldirective 111 into device-specific directive 112. Device-specificdirective 112 can be a form suitable for execution at target device 107to implement the directed configuration change.

Method 200 includes the platform-specific gateway sending the formsuitable for execution at the specified target device to the specifiedtarget device so as to realize the configuration change at the specifiedtarget device (203). For example, platform-specific gateway 104 can senddevice-specific directive 112 to target device 107.

Target device 107 can execute device-specific directive 112 to implementthe directed configuration change.

FIG. 3 illustrates an example computer architecture 300 that facilitatestranslating a device-specific operational data. Referring to FIG. 3,computer architecture 300 includes directive dispatcher 301, directiveprocessing modules 302, distribution component 303, platform-specificgateway 304, target device 307, data collector 308, and data persistencestore 309. Each of directive dispatcher 301, directive processingmodules 302, distribution component 303, platform-specific gateway 304,target device 307, data collector 308, and data persistence store 309can be connected to one another over (or be part of) a network, such as,for example, a Local Area Network (“LAN”), a Wide Area Network (“WAN”),and even the Internet. Accordingly, directive dispatcher 301, directiveprocessing modules 302, distribution component 303, platform-specificgateway 304, target device 307, data collector 308, and data persistencestore 309 as well as any other connected computer systems and theircomponents, can create message related data and exchange message relateddata (e.g., Internet Protocol (“IP”) datagrams and other higher layerprotocols that utilize IP datagrams, such as, Transmission ControlProtocol (“TCP”), Hypertext Transfer Protocol (“HTTP”), Simple MailTransfer Protocol (“SMTP”), etc.) over the network.

Directive dispatcher 301 can be configured similar to directivedispatcher 101. Directive dispatcher 301 can issue device-neutraldirectives targeted to one or more specified target devices. Thedevice-neutral directives can direct one or more specified targetdevices to implement a configuration change. When appropriate, directiveprocessing modules 302 can process issued device-neutral directives tomodify the device-neutral directives. Directive processing modules 302can apply business logic, in combination with operational data stored indata persistence sore 309, to make changes for specified target deviceor to comply with policy settings. In some embodiments, directiveprocessing modules 302 includes a plurality of modules that can accessdata from data persistence store 309 and interact with one another toprovide various features offered to a user (e.g., an IT admin).

Distribution component 303 is configured similar to distributioncomponent 103. Distribution component 303 can distribute adevice-neutral directive to one or more specified targeted devices.Distribution component 303 can receive a device-neutral directive. Fromthe devices distribution component 303 is aware of, distributioncomponent 303 can determine which devices are specified targeted devicesof the device-neutral directive. Distribution component 303 can forwardto the device-neutral directive on to the specified targeted devices.

Platform-specific gateway 304 is configured to interface between moreabstract device-neutral directives issued by directive dispatcher 111and more concrete device-specific directives for target device 307 (andother similar devices). More specifically, translation module 306 cantranslate a device-neutral directive into a form suitable for executionat target device 307 (and other similar devices). In some embodiments,platform-specific gateway 304 is one of a plurality of differentplatform-specific gateways.

Each of the plurality of different platform-specific gateways can beconfigured to interface between more abstract device-neutral directivesissued by directive dispatcher 301 and more concrete device-specificdirectives for corresponding target devices. Each of the plurality ofdifferent platform-specific gateways can also be configured to translatedevice-specific operational data into device neutral operational data.Each of the plurality of different platform-specific gateways can beconfigured for use with differently configured devices including any ofthe previously described devices. For example, platform-specific gateway104 can be configured for use with mobile phones, anotherplatform-specific gateway can be configured for use with personalcomputers, another platform-specific gateway can be configured for usewith network equipment, etc.

Platform-specific gateway 304 is further configured to collectoperational data from target device 307 (and other similar devices).Collected operational data can be in a device-specific data format andcan be related to a previously issued directive from directivedispatcher 301.

Platform-specific gateway 304 can interface between the device-specificdata format and a device-neutral data format. More specifically,translation module 306 can translate operational data in thedevice-specific data format into operational data in the device-neutralformat. The device-neutral format can be defined in schema 321. Thus,platform-specific gateway 304 (as well as any other platform-specificgateways) can translate operation data in a device-specific data formatinto operational data in the device-neutral format in accordance withschema 321.

Data collector 308 is configured to collect operational data in thedevice-neutral format from platform-specific gateway 304 (as well as anyother platform-specific gateways). Data collector 308 can storeoperation in the device-neutral format in data persistence store 309.Operation data stored in data persistence store 309 can be accessed bydirective processing modules 302. Directive processing modules 302 canapply business logic based on stored operational data to accesspreviously issued directives. Thus, output from prior directives can beused as feedback when processing new directives.

Target device 307 can be one of a variety of different devices, such as,for example, a personal computer, a mobile phone, a tablet, networkequipment, etc. or other previously described devices.

FIG. 4 illustrates a flow chart of an example method 400 for translatingdevice-specific operational data. Method 400 will be described withrespect to the components and data of computer architecture 300.

Remaining briefly at FIG. 3, directive dispatcher 301 can dispatchdevice-neutral directive 317 to target device 307 (as well as one ormore other devices). Device-neutral directive 317 can direct targetdevice 307 (as well as the one or more other devices) to implement aconfiguration change. When appropriate, directive processing modules 302can apply business logic to device-neutral directive 317. Device-neutraldirective 317 is then passed on to distribution component 103 fordistribution. Distribution component 303 can determine thatdevice-neutral component has been issued to target device 307. Inresponse, distribution component 303 can forward device-neutraldirective 317 to platform-specific gateway 304.

Platform-specific gateway 304 can receive device-neutral directive 317from distribution component 303. Translation module 306 can translatedevice-neutral directive 317 into device-specific directive 318.Device-specific directive 318 can be a form suitable for execution attarget device 307 to implement the directed configuration change.Platform-specific gateway 304 can send device-specific directive 318 totarget device 307.

Target device 307 can execute device-specific directive 318 to implementthe directed configuration change. As part of execution, target device307 can emit device-specific operational data 312 related to thedirected configuration change.

In general, operational data can include success/failure/detailsinformation relevant to the application of management directivessupplied from a gateway. Thus, device-specific operational data 312 caninclude success/failure/details information relevant to the applicationof device-specific directive 318.

Method 400 includes a platform specific gateway collecting operationaldata from a specified target device, the operational data in thedevice-specific data format, the operational data related to apreviously issued directive from a directive dispatcher (401). Forexample, platform-specific gateway 304 can collect device-specificoperational data 312. Device-specific operational data 312 can be in aformat specific to target device 307 (and other similar devices).Device-specific operational data 312 can be related to device-neutraldirective 317.

Method 400 includes the platform specific gateway translating theoperational data from the device-specific data format into thedevice-neutral data format, the device-neutral data format defined in adevice-neutral data schema (402). For example, translation module 306can translate device-specific operational data 312 into device-neutraloperational data 311. Device-neutral operational data 311 can be definedin a device-neutral format defined in schema 321.

Method 400 includes the platform-specific gateway submitting theoperational data in the device-neutral data format to a data collectionservice for storage in a data persistence store, the operational datafor subsequent use by business logic when processing issued directivesfrom the directive dispatcher (403). For example, platform-specificgateway 304 can submit device-neutral operational data 311 to datacollector 308 for storage in data persistence store 309.

Data collector 308 can receive device-neutral operational data 311 fromplatform-specific gateway 304. Data collector 308 can storedevice-neutral operational data 311 in data persistence store 309.Device-neutral operational data 311 can then be accessed by directiveprocessing modules 302 when processing directives from directivedispatcher 301.

FIG. 5 illustrates an example computer architecture 500 that facilitatesmanaging technology resources across multiple platforms.

Referring to FIG. 5, an admin user of computer architecture 500 canutilize administrator console software program 541. Software program 541can be a Web browser application, software installed on a computersystem, or an application (“app”) installed on a tablet or smart phone.The admin user can supply “directives” to via admin console 541.“Directives” can be commands, scripts, software packages, configurationmanifests, configuration policies, software licensing keys, workflows,user and hardware catalogs, and other such inputs that the admin desiresto implement over a population of devices and external systems.

Application Programming Interface (“API”) 501 can accept the directivesfrom admin console 541. API 501 can be a standards-compliant Internetprotocol following Simple Object Access Protocol (“SOAP”) orRepresentational State Transfer (“REST”) patterns. Alternatively, API501 can be a body of industry standard or proprietary Remote ProcedureCall (“RPC”) technologies.

API 501 can use directive dispatcher 502 to dispatch device-neutraldirectives to one or more directive processors 503. Directive processorscan be included for any number of features. As depicted, directiveprocessors 503 include policy computation 503A, remote tasks 503B,software distribution 503C, and others 503D. Core services 504 includeidentification of users and devices, the organization of users anddevices into groups for administrative convenience, and the binding ofdirectives to groups of users and/or devices. Any of directiveprocessors 503 can utilize the functionality of core services 504.

When new features are desired, new processors can be added to implementthe desired features. For example, to add a device backup feature, adirective processor used to back up devices can be added.

Data persistence store 542 can store data for use by directiveprocessors 503. Data collector 512 can collect data from and aboutentities that are being managed. Data collector 512 can store the datain data persistence store 542. Data persistence store 542 can take theform of a single database server, a cluster of database servers, or ascale cloud storage device. In some embodiments, a directive processorcan also implement its own data persistence.

Directive processors can 503 apply business logic to device-neutraldirectives received from directive dispatcher 502, in combination withdata from data persistence store 542, and other external data. Forexample, directive processors 503 can tabulate the results of priordirectives used, analyze directives for correctness and consistency withexisting standing directives, speculatively predict the impact ofimplementing a directive (i.e., impact analysis), determine historicaltrends and other data mining operations, package data payloads forsubsequent distribution, and so on. Processing device-neutral directivescan result in additional data being fed back into the system (e.g.analysis results saved at data persistence store 542) or feedback (e.g.reports generated for user inspection) being provide to the users (e.g.,an IT admin). Processing device-neutral directives can also result indata related to the implementation of directives being distributed tomanaged external devices and systems (e.g., any of on-premises externalsystem 516, off-premises external system 518, 3^(rd) party device agent544, native device agent 514, or legacy device client agent 517).

For example, an IT admin may issue a directive to install a softwarepackage on all computers in the Sales department. Software distributionprocessor 503C can analyze this device-neutral directive to determinethe suitability and compatibility of known computers in the Sales group,analyze the usage of available licenses against needed licenses, and soforth. A separate external actor external (e.g., an agent running oneach of the target devices) can then perform the installation steps oneach of the appropriate devices.

As such, since directive processors 503 process device-neutraldirectives, directive processors 503 are able to accomplish theirprocessing without having to understand the specific details of thevarious devices and/or external systems that are targets of management.Gateway adaptors (e.g., 507, 508, 509, 543, and 511) provide translationof device-neutral directives into a form suitable for execution inspecified target devices. Each gateway adaptor can be responsible fortranslating the abstract, device-neutral (or external system-neutral)directives into concrete, device-specific (or external system-specific)forms suitable for execution on specific targeted devices (or externalsystems).

Distribution routing component 506 can route device-neutral directivesto the appropriate gateway. Distribution routing component 506 can useinformation recorded about each device/external system in the datapersistence store 542 to facilitate routing device-neutral directives.

Various different types of gateway adaptors can be used. Thearchitecture is also generalized such that new gateway adaptors caneasily be added.

Device platform-specific gateway 543 can used to adapt device-neutraldirectives to those of a specific device platform. Deviceplatform-specific gateway 543 is responsible for implementing the“server/service” portion of the management protocol used by the deviceclient agent 114 for the target device platform. That is, deviceplatform-specific gateway 543 can translate a device-neutral directiveinto the “server/service” portion of the management protocol used by thedevice client agent 114.

For example, a device platform may be a mobile phone or table operatingsystem. The platform manufacturer can configure the device platform as aclosed system. The platform manufacturer can also include its ownmanagement agent, which it does not allow other parties to modify. Theplatform manufacturer can also develop an accompanying managementprotocol to interact with the management agent. In these embodiments,device platform-specific gateway 543 adapts a device-neutral directiveto the accompanying management protocol. As such, an IT admin can entera generic directive at admin console 541 to control a device that usesan otherwise closed and/or propriety management protocol.

For some device platforms and device client agent protocols, deviceplatform notification service 513 can be used. For such platforms andprotocols, device platform-specific gateway 543 can utilize thatnotification service. Continuing with the prior example, the platformmanufacturer can provide device platform notification service 513.

The interaction between the device platform-specific gateway 543, deviceplatform notification service 513, and native device agent 514 isbi-directional. That is, information can be collected and distributedbetween these components.

These and other patterns can be essentially repeated for other manageddevices. The patter can also be used for device platforms from the samevender. That is, a management system may include its own device clientagent. In that event, the translation performed by a gateway adaptor canbe significantly reduced.

Gateway adaptors can also be sued for managing prior (or legacy)editions of device clients. For example, legacy client/server gateway511 can be used to adapt a device-neutral directive to the accompanyingmanagement protocol used by legacy device client agent 517. Legacyclient/server gateway 511 can also adapt the directives expressed in oneversion of an IT management system to those of a previous version of thesame system. Adaption to previous versions can be useful when a legacyagent is designed to work with a prior version of a now revised system.Adaption to previous versions can be a way to include continuity ofmanagement of devices not yet upgraded or not able to be upgraded to theclient agent corresponding to the revised system.

Legacy client/server gateway 511 can also provide interoperability witha device client agent of a different (perhaps competing) managementsystem product. In this scenario, the Legacy client/server gateway 511can emulate the server portion of the competing management system, fromthe perspective of the device client agent.

The interaction between legacy client/server gateway 511 and legacydevice client agent 517 is bi-directional. That is, information can becollected and distributed between these components.

External on-premises system-specific gateway 507 and on-premises adaptor546 can be used to adapt device-neutral directives for use with anexternal software system that is installed on the premises of anenterprise, such as, for example, on-premise external system 516. Forexample, it may be that an IT admin wishes to manage the email mailboxesof the users in the enterprise. However, the email mailboxes are part ofan email system not part of an IT management system. The email systemcan include one or more servers present on the premises of the owningand/or operating enterprise.

Either the IT management system or the email system can supplyon-premises adaptor 546 to be run on-premises with the email system.On-premise adaptor 546 accepts data and commands from the externalon-premises system-specific gateway 507 and enacts those commands onon-premises external system 516. Alternately, on-premises externalsystem may itself provide facilities that external on-premisessystem-specific gateway 507 can utilize directly. In this embodiment,on-premises adaptor 546 may not be included. The interaction between thecomponents external on-premises system-specific gateway 507, on-premisesadaptor 546 and on-premises external system 516 is bi-directional. Thatis, information can be collected and distributed between thesecomponents.

The pattern is applicable to any number of other external systems,including document management, customer relationship management (CRM),complimentary IT management systems, etc.

External off-premises system-specific gateway 508 can be used to adaptdevice-neutral directives for use with an external software system thatis installed off the premises of an enterprise, such as, for example,off-premise external system 518. External off-premises system-specificgateway 508 can use service interfaces exposed by off-premises externalsystem 518 to implement directives and collect information. Off-premisesexternal system 518 can include services such as Office 365, GoogleApps, Salesforce, Dynamics Online, etc.

The interaction between External off-premises system-specific gateway508 and off-premises external system 518 is bi-directional. That is,information can be collected and distributed between these components.

Device platform-specific gateway 509 and 3^(rd) party intermediary 519can be used to adapt device-neutral directives to bridge use between anIT management system and systems/devices operated by a third party, suchas, 3^(rd) party device agent 544. Here, device platform-specificgateway 509 communicates with 3^(rd) party intermediary 519 thatutilizes 3^(rd) party device agent 544 also supplied by the externalsystem. That is, 3^(rd) party intermediary 519 handles communicationwith 3^(rd) party device agent 544. Device platform-specific gateway 509directs the external system utilizing interfaces provided by theexternal system.

The interaction between the Device platform-specific gateway 509, 3^(rd)party intermediary 519, and 3^(rd) party device agent 544 isbi-directional. That is, information can be collected and distributedbetween these components.

Gateway adaptors can also collect data from managed devices and externalsystems. The gateway adaptors can translate collected data into adevice-neutral format. The gateway adaptors can submit collected data inthe device-neutral format to data collector 112. Data collector 112 candefine device- and external system-neutral data schema. Gateway adaptorscan use the schema to formulate collected data into the device-neutralformat.

Data collector 512 can receive collected data (in the device-neutralformat) from gateway adaptors. Data collector 512 can apply furtherprocessing when appropriate. Data collector 512 can then store collecteddata in data persistence store 542. Directive processors 503 can referto the collected data when processing subsequent directives fromdirective dispatcher 502.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

What is claimed:
 1. A computer system, the computer system comprising:one or more hardware processors; system memory coupled to the one ormore hardware processors, the system memory storing instructions thatare executable by the one or more hardware processors; the one or morehardware processors executing the instructions stored in the systemmemory to manage a device, including the following: receive adevice-neutral configuration directive, the device-neutral configurationdirective having been modified based on operational data from one ormore other devices, the operational data including information relevantto the success or failure of applying the device-neutral configurationdirective at the one or more other devices; translate the device-neutraldirective into a device-specific configuration directive for the device;and send the device-specific configuration directive to implement aconfiguration change for the device.
 2. The computer system of claim 1,wherein the one or more hardware processors executing the instructionsstored in the system memory to receive a device-neutral configurationcomprise the one or more hardware processors executing the instructionsstored in the system memory to receive the device-neutral configuration,wherein one or more directive processors have modified thedevice-neutral configuration by one or more of: tabulating results,analyzing the device-neutral configuration directive, predicting theimpact of implementing the device-neutral configuration directive, anddetermining an historical trend with respect to the device-neutralconfiguration directive.
 3. The computer system of claim 1, wherein theone or more hardware processors executing the instructions stored in thesystem memory to translate the device-neutral configuration directiveinto a device-specific configuration comprises the one or more hardwareprocessors executing the instructions stored in the system memory totranslate the device-neutral configuration directive into a formsuitable for execution by a legacy device agent.
 4. The computer systemof claim 1, wherein the one or more hardware processors executing theinstructions stored in the system memory to translate the device-neutralconfiguration directive into a device-specific configuration comprisesthe one or more hardware processors executing the instructions stored inthe system memory to translate the device-neutral configurationdirective into a form suitable for execution by a 3^(rd) partyintermediary, the 3^(rd) party intermediary in communication with a3^(rd) party device agent.
 5. The computer system of claim 1, whereinthe one or more hardware processors executing the instructions stored inthe system memory to translate the device-neutral configurationdirective into a device-specific configuration comprises the one or morehardware processors executing the instructions stored in the systemmemory to translate the device-neutral configuration directive into aform suitable for execution by an off-premises external system.
 6. Thecomputer system of claim 1, wherein the one or more hardware processorsexecuting the instructions stored in the system memory to translate thedevice-neutral configuration directive into a device-specificconfiguration comprises the one or more hardware processors executingthe instructions stored in the system memory to translate thedevice-neutral configuration directive into a form suitable forexecution by an on-premises adaptor, the on-premises adaptor incommunication with an on-premises external system.
 7. The computersystem of claim 1, wherein the one or more hardware processors executingthe instructions stored in the system memory to translate thedevice-neutral configuration directive into a device-specificconfiguration comprises the one or more hardware processors executingthe instructions stored in the system memory to translate thedevice-neutral configuration directive into a form suitable forexecution by a native device agent.
 8. A computer system, the computersystem comprising: one or more hardware processors; system memorycoupled to the one or more hardware processors, the system memorystoring instructions that are executable by the one or more hardwareprocessors; the one or more hardware processors executing theinstructions stored in the system memory to manage a device, includingthe following: collect operational data in a device-specific format fromthe device in response to the device attempting to apply a configurationdirective to change configuration, the device-specific operational dataincluding information relevant to the success or failure of applying theconfiguration directive at the device; translate the operational data inthe device-specific format into operational data in a device-neutralformat; and send the operational data in the device-neutral format forstorage, the operational data providing feedback for use in modifyingthe device-neutral configuration directive for implementation at one ormore other devices.
 8. The computer system of claim 7, wherein the oneor more hardware processors executing the instructions stored in thesystem memory to collect operational data in a device-specific formatfrom the device comprises the one or more hardware processors executingthe instructions stored in the system memory to collect operational datain the device-specific format including details related to the successor failure of the device attempting to apply a device-specificconfiguration directive at the device.
 9. The computer system of claim7, wherein the one or more hardware processors executing theinstructions stored in the system memory to translate the operationaldata in the device-specific format into operational data in adevice-neutral format comprises the one or more hardware processorsexecuting the instructions stored in the system memory to translate theoperational data from a device client agent into the device-neutral dataformat.
 10. The computer system of claim 7, wherein the one or morehardware processors executing the instructions stored in the systemmemory to translate the operational data in the device-specific formatinto operational data in a device-neutral format comprises the one ormore hardware processors executing the instructions stored in the systemmemory to translate the operational data from an external system intothe device-neutral data format.
 11. The computer system of claim 7,wherein the one or more hardware processors executing the instructionsstored in the system memory to translate the operational data in thedevice-specific format into operational data in a device-neutral formatcomprises the one or more hardware processors executing the instructionsstored in the system memory to translate the operational data inaccordance with a device-neutral data schema.
 12. The computer system ofclaim 7, wherein the one or more hardware processors executing theinstructions stored in the system memory to send the operational data inthe device-neutral format comprises the one or more hardware processorsexecuting the instructions stored in the system memory to sendoperational data providing feedback for use in modifying one or moredevice-neutral configuration directives.
 13. The computer system ofclaim 7, wherein the one or more hardware processors executing theinstructions stored in the system memory to send operational data in thedevice-neutral format comprises the one or more hardware processorsexecuting the instructions stored in the system memory to sendoperational data in the device-neutral format to provide feedback foruse in modifying one or more device-neutral configuration directives byone or more of: tabulating results, analyzing the device-neutralconfiguration directive, predicting the impact of implementing thedevice-neutral configuration directive, and determining an historicaltrend with respect to the device-neutral configuration directive.
 14. Aprocessor implemented method for use a computer system, the processorimplementing method for managing a device, the processor implementedmethod comprising: a gateway adaptor collecting operational data in adevice-specific format from the device in response to the deviceattempting to apply a configuration directive to change configuration,the device-specific operational data including information relevant tothe success or failure of applying the configuration directive at thedevice; the gateway adaptor translating the operational data in thedevice-specific format into operational data in a device-neutral format;and the gateway adaptor sending the operational data in thedevice-neutral format for storage, the operational data providingfeedback for use in modifying the device-neutral configuration directivefor implementation at one or more other devices.
 15. The method of claim14, wherein a gateway adaptor collecting operational data in adevice-specific format comprises the gateway adaptor collect operationaldata in the device-specific format including details related to thesuccess or failure of the device attempting to apply a device-specificconfiguration directive at the device
 16. The method of claim 14,wherein the gateway adaptor translating the operational data in thedevice-specific format into operational data in a device-neutral formatcomprises the gateway adaptor translating operational data from anexternal system into the device-neutral data format.
 17. The method ofclaim 14, wherein the gateway adaptor translating the operational datain the device-specific format into operational data in a device-neutralformat comprises the gateway adaptor translating the operational data inaccordance with a device-neutral data schema.
 18. The method of claim14, wherein the gateway adaptor translating the operational data in thedevice-specific format into operational data in a device-neutral formatcomprises the gateway adaptor translating the operational data from adevice client agent into the device-neutral data format.
 19. The methodof claim 14, wherein the gateway adaptor sending the operational data inthe device-neutral format comprises the gateway adaptor sending theoperational data in the device-neutral format for use by one or more of:a policy computation directive processor, a remote task directiveprocessor, and a software distribution directive processor.
 20. Themethod of claim 14, wherein the gateway adaptor sending the operationaldata in the device-neutral format for storage comprises the gatewayadaptor sending the send operational data in the device-neutral formatto provide feedback for use in modifying one or more device-neutralconfiguration directives by one or more of: tabulating results,analyzing the device-neutral configuration directive, predicting theimpact of implementing the device-neutral configuration directive, anddetermining an historical trend with respect to the device-neutralconfiguration directive.